Modifying service provider context information to facilitate locating interceptor context information

ABSTRACT

A method and system for tracking context information of a service provider and interceptors of service provider requests is provided. An interceptor modifies a portion of service provider context information to reference interceptor context information associated with a client. When the client requests a service of the service provider, the client provides the modified service provider context information along with the request. The interceptor uses the reference of the modified portion of the service provider context information to retrieve its context information. The interceptor then restores the modified portion of the service provider context information to the original unmodified portion, which the interceptor retained as part of its context information. The interceptor then forwards the request along with the original service provider context information to the service provider.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation application of U.S. patentapplication Ser. No. 11/231,352, filed on Nov. 30, 2004, issued as U.S.Pat. No. 8,135,741, entitled “MODIFYING SERVICE PROVIDER CONTEXTINFORMATION TO FACILITATE LOCATING INTERCEPTOR CONTEXT INFORMATION,”which is incorporated herein in its entirety by reference.

BACKGROUND

Computer systems typically have services (e.g., file services) that areprovided to clients (e.g., an application program). The services mayimplement a high-level service using low-level operations. For example,a file system may provide high-level commands to open and read files,which are implemented using low-level operations, such as sector seekand sector read. To access a file, an application program can requestthe file system to open the file and then read the file. The file systemperforms the necessary low-level operations to perform the high-levelcommands (e.g., open and read). Thus, the developer of an applicationprogram does not need to understand or use the low-level operations, butrather can rely on the file system for performing the appropriatelow-level operations. The programs that request services of a serviceprovider are referred to as clients. To have a service performed on itsbehalf, a client sends a request to a service provider of that service.The service provider performs the request and returns a result such asdata or status information.

The requests for services can be satisfied synchronously orasynchronously by the service provider. When a request is satisfiedsynchronously, the client requesting the service waits until the servicecompletes before continuing. For example, a client may request a serviceby invoking a read file function of a file system that returns after thefile system has retrieved the data of the file. When a request issatisfied asynchronously, the client requesting the service does notwait until the service completes before continuing. However, when theservice does complete, the service provider then notifies the client.For example, a client may request a service by invoking a read filefunction of the file system. That function may return immediately to theclient so that the client can continue executing while the file systemis reading the file. When the read completes, the service providernotifies the client, for example, by calling a callback functionprovided by the client or sending an event notification to the client.

One example of a client/service provider model is the Transport DeviceInterface (“TDI”) of Microsoft Corporation. TDI defines the interactionsbetween a “transport provider” that implements a transport layer and a“transport client” that uses the services of the transport provider. Oneexample of a transport provider is a TCP driver, and one example of atransport client is a redirector of a file system. The redirectorinvokes functions provided by the TCP driver to send and receivemessages via TCP. Thus, the redirector can access files stored on othercomputing devices using the services of the TCP driver.

A service provider may need to maintain state information for the clientbetween requests received from the client. For example, when a filesystem opens a file on behalf of a client, the file system may need tomaintain a file control block so that when the client requests to readfrom that file, it can locate the file control block needed to satisfythe request. Such information may be referred to as “contextinformation.” One technique for tracking context information is toreturn a handle to the client. The handle may be an operating systemobject that contains or references context information for a serviceprovider session. A service provider session may be delimited by an openand a close request, such as an open file and a close file request. Theservice provider provides the handle to the client at the beginning ofthe session, and the client provides the handle to the service providerwith each request. This allows the service provider to locate contextinformation that is appropriate for the session. For example, the TDImodel specifies that a WINDOWS file object is used as the handle for aTDI session.

It is often desirable to be able to extend the functions provided by aservice provider. To support such extension, many systems allow forrequests for services made by clients to a service provider to beintercepted or hooked. When a client makes a request to a serviceprovider, an interceptor may receive the request and perform additionalprocessing before forwarding the request to the service provider. Theinterceptor may also intercept the response to the request and performadditional processing before forwarding the response to the client. FIG.1 is a diagram that illustrates the layered architecture of client,interceptors, and service provider. When client 101 wants to requestservices of the service provider 102, the client invokes a function,which may pass control to one or more interceptors 111-119. When eachinterceptor is invoked, it performs its processing and then forwards theinvocation to the next lower level interceptor. Ultimately, the lowestlevel interceptor invokes a function of the service provider.

Each interceptor, however, may need to maintain its context information.For example, an interceptor that simply logs to a file all invocationsto a service provider during a session may have context information thatincludes the handle returned by the file system when the log file wasopened or created. FIG. 2 is a diagram that illustrates one example ofhow interceptors track their context information. When client 210requests a service of service provider 220, it is forwarded throughinterceptors 250 and 260 to the service provider. The service providercreates context information that is represented as a context object 221(e.g., a file object). The service provider returns a reference to thecontext object to the lowest level interceptor, which forwards thereferences to the next higher level interceptor until the reference tothe context object is eventually forwarded to the client. Eachinterceptor has its own context information 251 and 261. To track itscontext information, an interceptor may create a hash table 255 and 265that contains references to its context information. The hash table ishashed based on the reference to the corresponding context objectprovided by the service. When the client makes another request of theservice provider in the same service provider session, it includes thereference to the context object in its request. When an interceptorreceives the request, the interceptor hashes the reference to locate itscontext information associated with that session. A difficulty with theuse of a hash table by each interceptor is that there can be a highoverhead in having to locate the appropriate context information for aninterceptor.

FIG. 3 is a diagram that illustrates another example of how interceptorstrack their context information. In this example, service provider 320creates context object 321 for a session of client 310. Each interceptor350 and 360 also creates a context object 351 and 361. When the lowestlevel interceptor receives the response from the service provider, itreplaces the reference to the context object of the service providerwith a reference to its context object before forwarding the response tothe next higher level interceptor. Eventually, the highest levelinterceptor forwards the response with a reference to its contextobject. Each interceptor includes as part of its context information thereference to the context object of the next lower layer. When the clientrequests a service of the service provider, it includes the referenceprovided by the highest-level interceptor, which is a reference to thecontext object for that interceptor. That interceptor uses the contextinformation of the context object and then forwards the request to thenext lower level interceptor using the reference provided by that nextlower level interceptor. Eventually, the service provider receives arequest that includes a reference to its context object. A difficultywith such an approach for tracking context information is that there canbe a high overhead in creating context objects, especially if thecreation of a context object requires a context switch from applicationmode to operating system mode.

SUMMARY

A method and system for tracking context information of a serviceprovider and interceptors of service provider requests is provided. Thecontext tracking system is implemented by an interceptor. Theinterceptor modifies a portion of service provider context informationto reference interceptor context information associated with a client.The interceptor then provides the modified context information to theclient that requested the service. When the client requests a service ofthe service provider, the client provides the modified service providercontext information along with the request. Upon receiving the requestfrom the client, the interceptor uses the reference of the modifiedportion of the service provider context information to retrieve itscontext information. The interceptor then restores the modified portionof the service provider context information to the original unmodifiedportion, which the interceptor retained as part of its contextinformation. The interceptor then forwards the request along with theoriginal service provider context information to the service provider.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram that illustrates the layered architecture of client,interceptors, and service provider.

FIG. 2 is a diagram that illustrates one example of how interceptorstrack their context information.

FIG. 3 is a diagram that illustrates another example of how interceptorstrack their context information.

FIG. 4 is a diagram that illustrates modification of service providercontext information when a session is initiated.

FIG. 5 is a diagram that illustrates restoration and modification ofservice provider context information when a service is requested duringa session.

FIG. 6 is a diagram that illustrates no modification of service providercontext information when a request is issued while another request isoutstanding.

FIG. 7 is a block diagram that illustrates components of the contexttracking system in one embodiment.

FIG. 8 is a flow diagram that illustrates processing of the contextobject created component in one embodiment.

FIG. 9 is a flow diagram that illustrates the processing of theintercept request component in one embodiment.

FIG. 10 is a flow diagram that illustrates the processing of thecallback function in one embodiment.

DETAILED DESCRIPTION

A method and system for tracking context information of a serviceprovider and interceptors of service provider requests is provided. Inone embodiment, the context tracking system is implemented by aninterceptor. The interceptor modifies a portion of service providercontext information to reference interceptor context informationassociated with a client. For example, when an interceptor receives aservice provider context object (e.g., a file object), the interceptorreplaces certain information of the context object with a reference tocontext information of the interceptor. The interceptor then providesthe modified context information to the client that requested theservice. When the client requests a service of the service provider, theclient provides the modified service provider context information alongwith the request. Upon receiving the request from the client, theinterceptor uses the reference of the modified portion of the serviceprovider context information to retrieve its context information. Theinterceptor then restores the modified portion of the service providercontext information to the original unmodified portion, which theinterceptor retained as part of its context information. The interceptorthen forwards the request along with the original service providercontext information to the service provider. In this way, theinterceptor can track its context information for the client without theoverhead of having to look up the context information and of having tocreate additional context objects.

In one embodiment, the context tracking system is implemented bymultiple interceptors that are layered between a client and a serviceprovider. A client initiates a session with a service provider bysending a request to the service provider, which is first intercepted bythe interceptor at the highest level. That interceptor forwards therequest to the next lower level interceptor. Eventually, the lowestlevel interceptor receives the request, performs the requested service,and sends a response to the client that includes service providercontext information, which is first intercepted by the lowest levelinterceptor. Upon receiving the response, the lowest level interceptorreplaces a portion of the service provider context information with areference to its context information, saves the portion beforemodification for later restoration, and forwards the response along withthe modified service provider context information to the interceptor atthe next higher layer. When the interceptor at the next higher layerreceives the response with the modified service provider contextinformation, it also replaces a portion of a service provider contextwith a reference to its context information, saves the portion beforemodification (which in this case is a reference to context informationof the interceptor at the next lower layer) for later restoration, andforwards the response along with the newly modified service providercontext information to the interceptor at the next higher layer.Eventually, the client receives the response with the modified serviceprovider context information which contains a reference to the contextinformation of the interceptor at the highest level.

When the client next requests a service from the service provider aspart of the same session, the client sends a request to the serviceprovider that includes the modified service provider information, whichis first intercepted by the interceptor at the highest level. Thatinterceptor uses the reference of the modified portion of the modifiedservice provider information to retrieve its context information. Thatinterceptor then replaces the portion of the service providerinformation that it previously modified with the unmodified portion thatit retained and forwards the request along with the restored serviceprovider context information, which is then intercepted by theinterceptor at the next lower level. That next lower level interceptoruses the reference of the restored portion of the service providercontext information to locate its context information. That interceptorthen restores the portion of the service provider context informationthat it previously modified with the retained portion and then forwardsthe request along with the restored service provider context informationto the interceptor at the next lower level. Eventually, the serviceprovider receives from the interceptor of the lowest level that requestalong with the service provider context information restored to theoriginal service provider context information. The service provider thenservices the request using the service provider context informationwithout having to know that the request had been intercepted and theservice provider context information had been modified by variousinterceptors.

In one embodiment, a client during a single session may request aservice of a service provider before a previous request has beencompleted; that is, the previous request is still outstanding. Forexample, if the requests are serviced synchronously, then one thread ofthe client may send a request by invoking a function, and before thatinvoked function returns, another thread of the client may send arequest by again invoking that function. If the requests are servicedasynchronously, then a thread of the client may send a request, andbefore the response is received asynchronously (e.g., by invocation of acallback function), the client (on the same or a different thread) maysend another request. Whenever a client sends a request during a sessionwhile another request of that session is outstanding, the serviceprovider context information is considered currently in use by theprevious request and the modified portion may be in an unknown state.For example, the modified portion may contain the original unmodifiedcontent, content newly modified by the service provider as part ofservicing the outstanding request, content modified by the interceptorsas the response from the service provider is intercepted, and so on.Thus, an interceptor cannot modify the service provider contextinformation without risk of overwriting content needed by the serviceprovider or an interceptor in processing the outstanding request.

To prevent an interceptor from overwriting content needed by the serviceprovider or another interceptor processing an outstanding request, aninterceptor reverts to a conventional technique of looking up itscontext information based on the reference to service provider contextinformation. When an interceptor receives a request, it determineswhether a modified portion of the service provider context informationcontains a reference to its context information. If not, the interceptorknows that the service provider or another interceptor is processinganother outstanding request. The interceptor may store a uniqueidentifier of itself when it modifies service provider contextinformation. If that unique identifier has been changed, then theinterceptor knows that the service provider or another interceptor isprocessing an outstanding request. In an alternative embodiment, aninterceptor may use a reference counting technique to determine whetherthere is an outstanding request. If a request is outstanding, then theinterceptor uses the reference (e.g., pointer to or address of) to theservice provider context information to locate the interceptor's contextinformation. For example, the interceptor may use a conventional hashtable data structure to locate its context information. The interceptorthen performs the processing of the request and forwards the request tothe interceptor at the next lower level without modifying the serviceprovider context information. The interceptor at the next lower levelagain detects that a unique identifier has been changed and looks up itscontext information using a conventional technique. Eventually, theinterceptor at the lowest level forwards the request to the serviceprovider without modifying the service provider context information. Theservice provider can then process the request with the server providercontext information that it expects. In this way, the interceptors canservice requests issued without having to look up their contextinformation so long as there is no outstanding request. If requests areseldom issued with outstanding requests, then the context trackingsystem may provide significant performance improvements overconventional techniques.

FIG. 4-6 are diagrams that illustrate an example of the modification andrestoration of server provider context information in one embodiment. Inthis example, only one interceptor is between the client and the serviceprovider. FIG. 4 is a diagram that illustrates modification of serviceprovider context information when a session is initiated. Initially, aclient issues 401 an open request that identifies a callback function(e.g., app::callback). The interceptor receives the request and forwards402 the open request with its own callback function (e.g.,int::callback) to the service provider. The service provider performsits services and when complete responds 403 to that request by invokingthe callback function provided by the interceptor. The service providerpasses a reference to a context object (i.e., “co”) that includes itscontext information. Upon receiving that response, the interceptorcreates 404 an interceptor context object (i.e., “ico”), which may becreated locally by the interceptor to avoid the overhead of a contextswitch. An interceptor context object may contain a reference to theinterceptor context information field, a count field, a context objectpointer field, and a retained service provider context informationfield. The interceptor context information field contains either areference to or the interceptor context information itself. The countfield contains a count of the number of outstanding requests. Ratherthan using its unique identifier to identify whether a request isoutstanding, an interceptor may use the count field. The interceptorincrements the count field for each request it processes and decrementsthe count field for each response it processes. A count of zero meansthat no request is outstanding. The context object pointer fieldcontains a pointer to the context object returned by the serviceprovider, which may be used to resolve hash collisions when a request isoutstanding. The retained service provider context information fieldcontains a copy of the portion of the service provider contextinformation to be modified so that it can be restored when a request isprocessed. The interceptor then modifies 405 a portion of the contextobject to reference the interceptor context object. The interceptor theninvokes the callback function provided by the client to respond to theservice request. When the client receives 406 the response, it stores areference to the context object for use in requesting services duringthe same session.

FIG. 5 is a diagram that illustrates restoration and modification ofservice provider context information when a service is requested duringa session. The client sends 501 a read request that includes thereference to the context object and identifies a callback function. Uponreceiving the request, the interceptor retrieves 502 a reference to theinterceptor context object from the received context object. Theinterceptor then restores 503 the context object using the contentretained in the interceptor context object and increments the count ofoutstanding requests. The interceptor then forwards the request with thecontext object and a callback function to the service provider. Theservice provider performs 504 its processing and then responds byinvoking the callback function of the interceptor and providing areference to the context object. Upon receiving the response, theinterceptor retrieves 506 the interceptor context object associated withthe callback function. The interceptor may use different entry points ofa callback function to identify the appropriate interceptor contextobject that is associated with that response. Alternatively, theinterceptor may perform conventional lookup techniques for locatinginterceptor context information. The interceptor then modifies 507 thecontext object to point to the interceptor context object, decrementsthe count of outstanding requests, and forwards the response by invokingthe callback function of the client. Upon receiving the response, theclient stores 508 a reference to the context object.

FIG. 6 is a diagram that illustrates no modification of service providercontext information when a request is issued while another request isoutstanding. The client sends 601 a request that identifies the contextobject. In this example, the context object contains a reference toservice provider context information, rather than interceptor contextinformation. When processing the outstanding request, the interceptorrestored the context object by overwriting the reference to theinterceptor context object with the retained content. Upon receiving thenext request, the interceptor detects 602 that a request is outstandingeither by checking for its unique identifier in the modified portion ofthe context object or by determining that the count field of theinterceptor context object is greater than zero. The interceptor thenlocates the interceptor context object using the reference to thecontext object and the hash table. Upon locating the interceptor contextobject, the interceptor increments 603 the count field to indicate thattwo requests are outstanding and forwards the request to the serviceprovider without modifying the context object. The service providerperforms 604 its processing and then responds by invoking the callbackfunction provided by the interceptor. Upon receiving the response, theinterceptor identifies 605 the appropriate interceptor context objectand decrements 606 the field count. The interceptor then invokes thecallback function of the client without modifying the context object.The client maintains 607 a reference to the context object for issuingthe next request. The context object contains the unmodified serviceprovider context information.

FIG. 7 is a block diagram that illustrates components of the contexttracking system in one embodiment. The context tracking system isimplemented by interceptors of client requests and service providerresponses. An interceptor 700 that implements the context trackingsystem includes a context object created component 701, an interceptrequest component 702, a callback component 703, an interceptorprocessing component 704, and a context data structure 705. The contextobject created component is invoked by the interceptor when a contextobject is provided by the service provider when a session is created.The intercept request component is invoked by the interceptor when arequest for service is intercepted. The intercept request componentrestores the service provider context information as appropriate. Thecallback component, which intercepts responses, is invoked when aresponse is provided by a service provider. The callback componentmodifies and retains the service provider context information asappropriate. The interceptor processing component performs the mainprocessing function of the interceptor. The context data structure,which may be a hash table, a binary tree, or other data structure, isused to locate interceptor context information when multiple requestsare outstanding. The interceptor may also use the context data structuredefined in context information when a response is received to locate theinterceptor context information.

The computing devices on which the context tracking system may beimplemented may include a central processing unit, memory, input devices(e.g., keyboard and pointing devices), output devices (e.g., displaydevices), and storage devices (e.g., disk drives). The memory andstorage devices are computer-readable media that may containinstructions that implement the context tracking system. In addition,the data structures and message structures may be stored or transmittedvia a data transmission medium, such as a signal on a communicationslink. Various communications links may be used, such as the Internet, alocal area network, a wide area network, or a point-to-point dial-upconnection.

The context tracking system may be implemented in various operatingenvironments that include personal computers, server computers,hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, programmable consumer electronics, networkPCs, minicomputers, mainframe computers, distributed computingenvironments that include any of the above systems or devices, and thelike. The context tracking system may also be implemented on computingdevices such as cell phones, personal digital assistants, consumerelectronics, home automation devices, and so on.

The context tracking system may be described in the general context ofcomputer-executable instructions, such as program modules, executed byone or more computers or other devices. Generally, program modulesinclude routines, programs, objects, components, data structures, and soon that perform particular tasks or implement particular abstract datatypes. Typically, the functionality of the program modules may becombined or distributed as desired in various embodiments.

FIG. 8 is a flow diagram that illustrates processing of the contextobject created component in one embodiment. The component is invokedwhen the interceptor receives a newly created context object. In block801, the component creates an interceptor context object that contains areference to the interceptor's context information. In block 802, thecomponent initializes the count field of the interceptor context objectto zero to indicate that no requests are outstanding. In block 803, thecomponent sets the context object pointer field of the interceptorcontext object to point to the context object. In block 804, thecomponent retains the service provider context information that is beingmodified by storing it in the service provider context field of theinterceptor context object. In block 805, the component stores theinterceptor context object using a hash table and hashing on thereference to the context object. In block 806, the component modifiesthe context object to point to the interceptor context object and thencompletes.

FIG. 9 is a flow diagram that illustrates the processing of theintercept request component in one embodiment. The component is invokedby an interceptor to restore the context object. In decision block 901,if another request is outstanding, then the component continues at block904, else the component continues at block 902. In block 902, thecomponent retrieves the reference to the interceptor context object fromthe modified portion of the context object. In block 903, the componentrestores the service provider context object using the retained contentand continues at block 906. In block 904, the component searches thehash table for the interceptor context object. In decision block 905, ifthe interceptor context object was found in the hash table, then thecomponent continues at block 906, else the component continues at block911. In block 906, the component increments the count field of theinterceptor count object to indicate that one more request isoutstanding. In block 907, the component sets the interceptor context tothe interceptor context of the interceptor context object so that theinterceptor can perform its processing in the appropriate context. Inblock 908, the component processes the request with the interceptorcontext. In block 909, the component sets the callback routine toidentify the interceptor context object. In block 910, the componentforwards to the service provider or the interceptor at the next lowerlevel the request that includes the restored service provider contextobject and the callback function and then completes. In block 911, thecomponent performs the processing of the request when contextinformation is not available.

FIG. 10 is a flow diagram that illustrates the processing of thecallback function in one embodiment. In block 1001, the componentretrieves the interceptor context object for the interceptor. In block1002, the component decrements the count filed of the interceptorcontext object to indicate that one less request is outstanding. Indecision block 1003, if no more requests are outstanding, then thecomponent continues at block 1004, else the component continues at block1005. In block 1004, the component modifies a portion of the contextobject to point to the interceptor context object. The component mayalso retain a new copy of the unmodified content in the interceptorcontext object if the service provider or interceptors are allowed tomodify that content after creation of the context object. In block 1005,the component then forwards the response by invoking the callbackfunction of the application and then completes.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims. Accordingly, the invention isnot limited except as by the appended claims.

1. A method performed a computing device for tracking context of aservice provider by an interceptor of requests from a client to theservice provider, the method comprising: receiving, from the serviceprovider, service provider context information; generating interceptorcontext information representing state information of the interceptormaintained for communication between the client and the serviceprovider; generating a copy of a portion of the service provider contextinformation, the copy representing a retained portion of the serviceprovider context information; modifying the service provider contextinformation to replace the copied portion with a reference to theinterceptor context information, the replaced portion representing amodified portion of the service provider context information; providingthe modified service provider context information to the client; andupon receiving from the client a request for a service of the serviceprovider, the request including the modified service provider contextinformation, retrieving, from the modified portion of the modifiedservice provider context information included in the request, thereference to the interceptor context information representing the stateinformation for communication between the client and the serviceprovider; replacing the modified portion of the modified serviceprovider context information included in the request with the retainedportion to restore the service provider context information; andforwarding the request to the service provider, the forwarded requestincluding the restored service provider context information.
 2. Themethod of claim 1 wherein the retained portion of the service providercontext information is stored in association with the interceptorcontext information.
 3. The method of claim 2 including, upon receivingfrom the client a request for a service of the service provider,retrieving the retained portion stored in association with theinterceptor context information identified by the retrieved reference.4. The method of claim 1 including upon receiving from the client arequest for a service of the service provider while a request for aservice of that service provider is still outstanding, not modifying theservice provider context information that was previously modified. 5.The method of claim 1 including upon receiving from the client a requestfor a service of the service provider while a request for a service ofthat service provider is still outstanding, using a reference to theservice provider context information to locate interceptor contextinformation.
 6. The method of claim 1 including: upon receiving from theclient a request for a service of the service provider while a requestfor a service of that service provider is still outstanding, using areference to the service provider context information to locateinterceptor context information; and not modifying the modified serviceprovider context information.
 7. A computer-readable storage mediumstoring computer-executable instructions for controlling a computingdevice to track context to an interceptor of requests from a client to aservice provider, by a method comprising: receiving by the interceptorservice provider context information; generating interceptor contextinformation representing state information of the interceptor forcommunication between the client and the service provider; generating acopy of a portion of the service provider context information, the copyrepresenting a retained portion of the service context information asreceived; modifying the service provider context information to replacethe copied portion with a reference to the interceptor contextinformation, the replaced portion representing a modified portion of theservice provider context information; forwarding the modified serviceprovider context information on to the client; and upon receiving arequest for a service of the service provider, the request including themodified service provider context information, retrieving, from themodified portion of the modified service provider context informationincluded in the request, the reference to the interceptor contextinformation representing the state information of the interceptor;replacing the modified portion of the modified service provider contextinformation included in the request with the retained portion to restorethe service provider context information; and forwarding the request onto the service provider, the forwarded request including the restoredservice provider context information.
 8. The computer-readable storagemedium of claim 7 wherein the interceptor receives the service providercontext information from a next lower-level interceptor and forwards therequest on to the service provider via the next lower-level interceptor.9. The computer-readable storage medium of claim 8 wherein theinterceptor forwards the modified service provider information on to theclient via a next higher-level interceptor and receives the request forservice from the next higher-level interceptor.
 10. Thecomputer-readable storage medium of claim 7 wherein the interceptorforwards the modified service provider information on to the client viaa next higher-level interceptor and receives the request for servicefrom the next higher-level interceptor.
 11. The computer-readablestorage medium of claim 7 wherein the retained portion of the serviceprovider context information is stored in association with theinterceptor context information.
 12. The computer-readable storagemedium of claim 11 including, upon receiving a request for a service ofthe service provider, retrieving the retained portion stored inassociation with the interceptor context information identified by theretrieved reference.
 13. The computer-readable storage medium of claim 7including upon receiving a request for a service of the service providerwhile a request for a service of that service provider is stilloutstanding, not modifying the service provider context information thatwas previously modified.
 14. The computer-readable storage medium ofclaim 7 including upon receiving from the client a request for a serviceof the service provider while a request for a service of that serviceprovider is still outstanding, using a reference to the service providercontext information to locate interceptor context information.
 15. Acomputing device for tracking context of provided to an interceptor ofrequests from a client to a service provider, comprising: a memorystoring computer-executable instructions of an interceptor that:receives service provider context information; generates interceptorcontext information representing state information of the interceptorfor communication between the client and the service provider; generatesa copy of a portion of the service provider context information, thecopy representing a retained portion of the service context informationas received; modifies the service provider context information toreplace the copied portion with a reference to the interceptor contextinformation, the replaced portion representing a modified portion of theservice provider context information; forwards the modified serviceprovider context information on to the client; and upon receiving arequest for a service of the service provider, the request including themodified service provider context information, retrieves, from themodified portion of the modified service provider context informationincluded in the request, the reference to the interceptor contextinformation representing the state information of the interceptor;replaces the modified portion of the modified service provider contextinformation included in the request with the retained portion to restorethe service provider context information; and forwards the request on tothe service provider, the forwarded request including the restoredservice provider context information; and a processor for executing thecomputer-executable instructions stored in the memory.
 16. The computingdevice of claim 15 wherein the interceptor receives the service providercontext information from a next lower-level interceptor and forwards therequest on to the service provider via the next lower-level interceptor.17. The computing device of claim 16 wherein the interceptor forwardsthe modified service provider information on to the client via a nexthigher-level interceptor and receives the request for service from thenext higher-level interceptor.
 18. The computing device of claim 15wherein the interceptor forwards the modified service providerinformation on to the client via a next higher-level interceptor andreceives the request for service from the next higher-level interceptor.19. The computing device of claim 15 wherein the retained portion of theservice provider context information is stored in association with theinterceptor context information.
 20. The computing device of claim 16wherein the interceptor, upon receiving a request for a service of theservice provider, retrieves the retained portion stored in associationwith the interceptor context information identified by the retrievedreference.